|
|
Am 16.06.2021 um 20:14 schrieb ingo:
> When I move I put dates on boxes. Boxes that have not been opened are
> thrown out unopnend after two years unless they have a red sticker.
So, following that logic, should we just throw away all the sample
scenes altogether? ;)
> Thinking about this and backwards compatibilty, would it be easier to keep
> a few startegic versions of POV-Ray running, executing, compiling for
> current and future compilers and OS's (3.1g, 3.5, 3.7)? This could give a
> dev more freedom to break things and probably to keep the source cleaner?
> It would also kind of solve the old image problem.
For a purely command-line only thingumajig - no graphical output
whatsoever - that might be feasible. But porting a graphical user
interface between different OS versions, different operating systems,
hardware platforms etc. over and over again... that will almost
inevitably lead to feature rot, as features not easily portable and not
strictly necessary will be "temporarily" disabled, others not necessary
on a particular platform will be amputated and not revived when ported
to a platform that might benefit from it, and so on...
In the end, the UI versions of the old pieces of software will become
unusable hunks of rotted code, that aren't worthy of keeping alive.
And then some day command-line interfaces may go out of fashion
entirely, and the command-line-only strain of the software will suffer
the same fate, too.
Also, each time the programming language standards change, the old code
will have to be adapted to work with the new standard. Same deal there:
Code that was originally clean and sane becomes patched up only at the
edges that openly exhibit issues, while other portions may be forgotten
and quietly slip out of alignment, until some day the whole thing comes
crashing down, because at its core, hidden under layers of patches, its
bones have become brittle. And the libraries our code relies on will
also be moving targets, which will break stuff every now and then. Which
is especially problematic when it's something we're using as extensively
as the boost thread library.
At some point in time, it will probably be easier to just install an
emulator or virtual machine, and run old binaries that way.
We've been doing something along those lines with POV-Ray v3.7, at least
as far as the Unix version goes - putting out maintenance releases to
keep it compatible with whatever comes our way. But we won't be able to
keep it supported forever, especially on the Windows platform. We'd
eventually need to write a brand new front-end for it. Which takes time
and energy, because the front-end interface differs from that of v3.8.
And eventually v3.7 will succumb to boost rot, because newer versions of
boost will grow more and more incompatibilities with our code, and
eventually cease to even support what we're using it for, because that
portion of boost is effectively outdated already; while the older
versions of boost will grow more and more incompatibilities with modern
compilers, and be unavailable for more and more modern target platforms.
And ripping out boost and replacing it with something else may turn out
to be more work than it's worth, due to how intensively we were using it
in v3.7. At that point, v3.7 will go the way of the Dodo.
The good news is that v3.8 will be reasonably close to v3.7 in its
behavior, and hopefully work as a plug-in replacement. And work for
ripping out boost (the most extensively used portions anyway) had almost
finished in v3.8 (in fact it had, but we're reverting back to before
that for v3.8.0), so it'll be much less susceptible to poorly aging
libraries, and thus might be a lot easier to keep alive in the long run
than poor old v3.7.
In fact, it might even be easier to revive any of the older versions
than to keep v3.7 alive. v3.6.2 and earlier versions didn't use boost at
all. Of course they also didn't support multithreading.
Well, so much for my crystal ball peek into the future, anyway. Only
time will tell how much I'm over- or underestimating the troubles involved.
> Dreaming, maybe a future povray parser could just start an other engine
> depending on the #version of the scene file.
>
> (I have no idea of the complexity of all that)
That won't fly at all. At best, the combo of parser and render engine
could be exchanged. But even that would require a well-defined interface
to plug those pieces into a front-end. We don't have such a thing at
present, and I dare say we never will. Not a stable one, at any rate.
Which defies the whole idea. Oddly enough, we'll probably continue trying.
Well, actually we currently have _two_ such interfaces: The POVMS
interface and the VFE. Neither is anywhere close to intuitive though (at
least *I* haven't gotten a good grasp on either of them yet, and it's
not like I'm totally new to the source code), and I wouldn't want to
have to interface to either of them. And neither seems to be
particularly suited to just exchanging the back-end on the fly.
> Is there anything of a time frame, weeks, months, less than a year and a
> halve? Currently my time is limited but it will change towards the end of
> the year.
Folks at dev team level are itching to get v3.8.0 out as soon as quality
concerns permit. I'm pretty sure we'll have the first beta before the
month is over. How quickly things progress from then on depends; my
estimates vary between anything from another month (when I'm feeling
excessively optimistic) to half a year (when I'm extrapolating from past
frustration). It certainly won't take as long as the v3.7.0 beta phase.
Post a reply to this message
|
|